CSDV3017 · Lecture 3 · 09 Jun 2026 · 14:00–15:00
DevOps Tools
& Toolchain
CI · CD · Testing · Deployment · Monitoring · DevSecOps · SRE

BTech CSE 6th Semester · School of Computer Sciences · UPES Dehradun

Faculty: Dr. Mohsin Furkh Dar
Mode: Online · MS Teams
Session: Tue 14:00 – 15:00
Week: 1 of 6

Today's Learning Objectives

  • Understand the role of tools across the full DevOps lifecycle
  • Identify key tools for Continuous Development, Integration, and Testing
  • Explain Continuous Deployment and Monitoring with their toolsets
  • Understand DevSecOps and the "shift-left" security approach
  • Distinguish DevOps from Site Reliability Engineering (SRE)
  • Map a complete, end-to-end DevOps toolchain

Recap from Lecture 2

  • DevOps history: Waterfall → Agile Manifesto (2001) → DevOpsDays Ghent (2009) → GitOps/AIOps
  • 8 core DevOps practices: CI, CD, IaC, Monitoring, Collaboration, DevSecOps, Containers, Feedback
  • Agile vs DevOps: scope, team, delivery cadence, and how they complement each other
  • Kanban (WIP limits, continuous flow) and Scrum (sprints, roles, events, artifacts)
The Big Picture

Tools Across the
DevOps Lifecycle

No single tool does everything. A DevOps toolchain is a curated set of tools — one or more for each stage — that together automate and accelerate the path from idea to production.

Plan
📋Jira
Trello
Azure Boards
Develop
💻VS Code
IntelliJ
Git
Build / CI
🔨Jenkins
GitHub Actions
GitLab CI
Test
🧪JUnit
Selenium
SonarQube
Release / CD
📦Spinnaker
ArgoCD
AWS CodePipeline
Deploy
🚀Docker
Kubernetes
Ansible
Monitor
📊Prometheus
Grafana
Datadog
🎯
Right Tool, Right Stage
Every stage of the lifecycle has specialised tools. Mixing or skipping stages creates gaps that slow delivery and increase risk.
🔗
Integration is Everything
Tools must integrate seamlessly. A Jenkins build should automatically trigger a SonarQube scan, push to Docker Hub, and notify Slack — with zero manual handoffs.
📖
Open Source First
Most industry-standard DevOps tools are open source (Jenkins, Prometheus, Kubernetes, Ansible). Vendor platforms (AWS, Azure, GCP) wrap these with managed services.
Stage 1

Continuous
Development

Continuous Development (CD) is the first stage of the DevOps lifecycle — covering planning and coding. It emphasises short development cycles, version control discipline, and fast feedback from the codebase.

Definition

Continuous Development is the practice of continuously writing, refining, and committing code in small increments using version control, ensuring the codebase is always in a workable state and ready for the next stage of the pipeline.

🗂️
Version Control
Every line of code is tracked. Git is the universal standard. GitHub, GitLab, and Bitbucket host repositories and enable collaboration at scale.
🌿
Branching Strategies
Gitflow: feature/release/hotfix branches.
Trunk-based: short-lived branches, merge to main daily. Preferred in high-velocity DevOps teams.
📝
IDEs & Editors
VS Code, IntelliJ IDEA, PyCharm. Extensions for linting, formatting, and integrated terminal make them the developer's primary environment.
📦
Package & Dependency Mgmt
npm (Node.js), pip (Python), Maven/Gradle (Java), Cargo (Rust). Lock files ensure reproducible builds across environments.
🔍
Code Review
Pull Requests (PRs) enforce peer review before merging. GitHub, GitLab, and Gerrit provide inline commenting, approval workflows, and status checks.
📋
Issue & Project Tracking
Jira, Trello, Linear, and GitHub Issues link code commits to user stories and tasks, maintaining traceability from requirement to release.
Stage 2

Continuous
Integration (CI)

CI is the practice of automatically building and testing every code commit. It is the engine that keeps the shared codebase healthy and eliminates the "integration hell" of infrequent merges.

Definition

Continuous Integration is the practice of merging developer code changes into a shared repository frequently — at least daily — where each merge triggers an automated build and test pipeline to detect problems early.

What happens on every commit →

⬆️Code Push
to Git
🔨Automated
Build
🧪Unit &
Integration Tests
🔍Static Code
Analysis
📊Test
Report
Pass:
Merge
|
🚨Fail:
Notify Dev

Key CI Tools — industry standard

🔧
Jenkins
Open-source · most widely used
GitHub Actions
Native to GitHub repos
🦊
GitLab CI/CD
Built into GitLab platform
🔵
Azure DevOps Pipelines
Microsoft cloud-native
☁️
CircleCI
Cloud-first, YAML config
🟠
Travis CI
Popular for open-source
CI Rule of Thumb: If the build is broken, fixing it is the team's highest priority — not starting new work. A broken main branch blocks everyone. Fix forward or roll back immediately.
Stage 3

Continuous
Testing

In DevOps, testing is not a phase — it is a continuous, automated activity embedded throughout the pipeline. The goal is to get fast, reliable feedback at every stage.

Unit Testing
Test individual functions or methods in isolation. Fastest feedback. Run on every commit. Tools: JUnit (Java), PyTest (Python), Jest (JS). Target: >80% code coverage.
🔗
Integration Testing
Test interactions between modules, services, or databases. Slower than unit tests. Tools: Postman, REST Assured, TestContainers.
🖥️
UI / End-to-End Testing
Simulate real user interactions in a browser. Slowest but highest confidence. Tools: Selenium, Playwright, Cypress.
📈
Performance Testing
Measure response times, throughput, and system behaviour under load. Tools: JMeter, k6, Gatling. Run in staging before production.
🔍
Static Analysis (SAST)
Scan source code for bugs, vulnerabilities, and style violations without running it. Tools: SonarQube, ESLint, Checkstyle, Bandit.
🧩
Contract Testing
Verify API contracts between microservices without deploying them together. Tool: Pact. Essential in distributed systems to prevent breaking changes.
The Test Pyramid

Many fast unit tests at the base → fewer integration tests in the middle → very few slow UI tests at the top. This shape keeps CI pipelines fast and feedback immediate.

Stages 4 & 5

Continuous Delivery
& Deployment

After code passes CI and testing, it must be packaged and shipped. Two related practices govern this — and they are often confused.

📬
Continuous Delivery
Code is always in a deployable state. Every change is automatically built, tested, and prepared for release. Deployment to production requires a manual approval step. The team decides when to ship.
🚀
Continuous Deployment
Every change that passes all automated tests is automatically deployed to production — with zero human approval. Requires very high test confidence and robust monitoring. Example: Netflix, Amazon.

Key Deployment Strategies

🔵🟢 Blue-Green Deployment
Two identical environments (Blue = live, Green = new). Traffic switched from Blue to Green instantly. Easy rollback: switch back.
🐦 Canary Release
New version deployed to a small % of users (e.g. 5%). If metrics are healthy, gradually roll out to 100%. Reduces blast radius of bad releases.
🔄 Rolling Update
Replace old instances with new ones incrementally. Zero downtime, but both versions run simultaneously during the rollout. Used natively by Kubernetes.
🏳️ Feature Flags
Deploy code with features hidden behind flags. Enable or disable features per user segment without redeployment. Tools: LaunchDarkly, Flagsmith.
🗂️ IaC for Deployment
Infrastructure provisioned as code alongside the app. Terraform, Ansible, CloudFormation ensure consistent environments every time.
Stage 6

Continuous
Monitoring

Monitoring closes the feedback loop. Without observability into production, teams are flying blind. Monitoring is not optional — it is the foundation of reliability and the source of data for every improvement.

Three Pillars of Observability

Metrics — numerical measurements over time (CPU, latency, error rate)  ·  Logs — timestamped records of events  ·  Traces — end-to-end journey of a request across microservices

99.9%
Uptime SLA
142ms
Avg Response Time
0.3%
Error Rate
4.2k
Req/sec

Monitoring & Observability Tools — ecosystem

🔥
Prometheus
Metrics collection & alerting
📊
Grafana
Dashboards & visualisation
🐘
ELK Stack
Elasticsearch · Logstash · Kibana
🐶
Datadog
SaaS APM & infrastructure
🟠
Jaeger
Distributed tracing
📟
PagerDuty
Incident management & on-call
🔔
Alertmanager
Prometheus alert routing
☁️
AWS CloudWatch
AWS-native monitoring
🚨 Alerting
Define thresholds. Alert on anomalies. Route to the right on-call engineer. Avoid alert fatigue with smart grouping and silencing.
📝 Log Aggregation
Centralise logs from all services. Correlate by trace ID. Search in seconds. ELK Stack and Loki (Grafana) are the go-to solutions.
🔄 Feedback to Dev
Production metrics feed back into the planning stage. New bugs → new Jira tickets. Latency spikes → new performance stories. The ∞ loop in action.
Security Integration

DevSecOps:
Security is Everyone's Job

DevSecOps extends DevOps by integrating security practices at every stage of the pipeline — not as a gate at the end, but as a shared responsibility from the first line of code.

Definition

DevSecOps stands for Development, Security, and Operations. It embeds security controls, testing, and culture into the CI/CD pipeline so that security is built in, not bolted on. The guiding principle: shift left — catch security issues as early as possible.

Shift-Left Security — Security at Every Stage

Plan
Threat modelling
Security requirements
OWASP checklist
Code
Pre-commit hooks
Secret scanning
IDE security plugins
Build / CI
SAST (SonarQube)
Dependency scan
Snyk / OWASP DC
Test
DAST (OWASP ZAP)
Penetration testing
Container image scan
Deploy / Run
Runtime protection
WAF / IDS
Compliance audits
🔍
SAST
Static Application Security Testing — analyse source code for vulnerabilities without running it. Tools: SonarQube, Semgrep, Checkmarx. Run in CI pipeline.
🌐
DAST
Dynamic Application Security Testing — attack a running application to find runtime vulnerabilities. Tools: OWASP ZAP, Burp Suite. Run in staging.
📦
SCA — Dependency Scanning
Software Composition Analysis — scan third-party libraries for known CVEs. Tools: Snyk, OWASP Dependency-Check, Dependabot. Automated on every build.
🔒
Secrets Management
Never store credentials in code. Tools: HashiCorp Vault, AWS Secrets Manager, GitHub Secret Scanning. Enforce via pre-commit hooks.
🐳
Container Security
Scan Docker images for OS and package CVEs before pushing to registry. Tools: Trivy, Clair, Snyk Container. Use minimal base images.
Key Distinction

DevOps vs
Site Reliability Engineering

DevOps and SRE are two of the most important concepts in modern software operations. They share goals but differ in origin, structure, and how they achieve reliability.

🔁
DevOps
Origin: Industry-wide movement (2009)
Philosophy: Culture + practices + automation
Goal: Break silos, speed up delivery, improve collaboration
Scope: Full lifecycle — Dev through Ops
Teams: Cross-functional DevOps teams
Success Metric: Deployment frequency, lead time, MTTR
"What": Principles and mindset — not prescriptive
🛡️
Site Reliability Engineering (SRE)
Origin: Google (2003, Ben Treynor Sloss)
Philosophy: Apply software engineering to operations problems
Goal: Build and maintain large-scale reliable systems
Scope: Production reliability, availability, performance
Teams: Dedicated SRE team (software + ops skills)
Success Metric: SLIs, SLOs, error budgets
"How": Specific, prescriptive implementation
SRE Concept 1
SLI — Service Level Indicator
A quantitative measure of service behaviour. E.g., request latency, error rate, availability percentage.
SRE Concept 2
SLO — Service Level Objective
A target value for an SLI. E.g., "99.9% of requests served within 200ms." The reliability goal the team commits to.
SRE Concept 3
Error Budget
The allowed amount of unreliability. 99.9% SLO = 0.1% error budget = ~8.7 hours/year. If budget is spent, slow releases; if ample, move fast.
SRE Concept 4
Toil Elimination
SREs spend ≤50% time on toil (repetitive manual ops work). The rest is engineering to automate and eliminate that toil permanently.
Google's framing: "SRE is what happens when you ask a software engineer to design an operations team." DevOps and SRE are complementary — SRE is a concrete implementation of DevOps principles at scale. — Benjamin Treynor Sloss, Google VP Engineering
Side-by-Side

DevOps vs SRE:
Detailed Comparison

Understanding where DevOps ends and SRE begins helps organisations decide which roles and structures to adopt as they scale their engineering organisations.

DimensionDevOpsSRE
Originated atIndustry movement (Flickr/Allspaw 2009)Google (Ben Treynor, 2003)
Primary FocusCollaboration, speed, breaking silosReliability, scalability, availability
PrescriptivenessPrinciples & culture — not prescriptiveHighly specific practices and metrics
Team StructureEmbedded in product teamsDedicated SRE team, serves other teams
Key MetricsDORA (deploy freq, lead time, CFR, MTTR)SLIs, SLOs, error budgets, toil %
Automation GoalAutomate the delivery pipeline (CI/CD)Automate operations to reduce toil
On-Call RotationShared "you build it, you run it"Structured SRE on-call with runbooks
Incident ResponseBlameless post-mortems, fast MTTRFormal incident management, RCA docs
Relationship✓ SRE implements DevOps principles with engineering rigour — they are complementary, not competing
🏢
When to use DevOps?
Any team that wants to ship faster, collaborate better, and reduce silos. Works at any scale — startups to enterprises.
🌐
When to adopt SRE?
At scale — when reliability requirements are high, on-call burden is unsustainable, and you need rigorous SLO-based engineering practices.
🤝
Using Both Together
Large organisations (Google, Netflix, LinkedIn) use SRE teams to support DevOps product teams — providing reliability infrastructure and guidance.
End-to-End

The Complete
DevOps Toolchain

A DevOps toolchain is the full set of tools integrated together to support continuous delivery — from planning to monitoring. Each tool hands off to the next automatically.

Plan
Jira
Trello
Azure Boards
Linear
GitHub Issues
Develop
Git
GitHub
GitLab
VS Code
IntelliJ
Bitbucket
Build / CI
Jenkins
GitHub Actions
GitLab CI
CircleCI
Azure Pipelines
Travis CI
Test
JUnit
Selenium
Cypress
JMeter
SonarQube
Snyk
OWASP ZAP
Release / CD
Spinnaker
ArgoCD
AWS CodePipeline
Harness
Flux
Deploy / IaC
Docker
Kubernetes
Terraform
Ansible
Puppet
Helm
Monitor
Prometheus
Grafana
ELK Stack
Datadog
Jaeger
PagerDuty
↺ feedback loop back to Plan
Lecture Wrap-up

Key Takeaways

What you should be able to explain after today's session:

  • 01A DevOps toolchain covers every stage of the lifecycle — Plan, Develop, Build, Test, Release, Deploy, Monitor — with specialised, integrated tools at each stage.
  • 02Continuous Development relies on Git, branching strategies, IDEs, and code review (PRs) to keep the codebase always workable and collaborative.
  • 03Continuous Integration automatically builds and tests every commit. Key tools: Jenkins, GitHub Actions, GitLab CI. A broken build is the team's top priority.
  • 04Continuous Testing embeds unit, integration, UI, performance, and security tests into the pipeline using the test pyramid model (many fast → few slow).
  • 05CD = Continuous Delivery (manual approval gate) vs Continuous Deployment (fully automated to production). Key strategies: Blue-Green, Canary, Rolling, Feature Flags.
  • 06Continuous Monitoring uses the three pillars (Metrics, Logs, Traces) via Prometheus, Grafana, ELK, and Datadog to close the feedback loop from production back to planning.
  • 07DevSecOps shifts security left — embedding SAST, DAST, SCA, secrets scanning, and container scanning throughout the pipeline rather than at the end.
  • 08SRE (Google, 2003) implements DevOps principles with engineering rigour: SLIs, SLOs, error budgets, and toil elimination. Complementary to — not a replacement for — DevOps.
📚
Next Session
Week 2 · Mon, 15 Jun — Business Needs for DevOps; Why DevOps is needed? (Unit II)
💡
Think About This
If you were setting up a CI/CD pipeline for a university project, which 3–4 tools from today's toolchain would you start with, and why?
🔗
Academic Portal
Resources & slides: mohsinfurkh.github.io/academic-portal
arrow keys · swipe on mobile